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Reply dated: August 20, 2009 

Remarks 

This Reply is in response to the Office Action mailed May 28, 2009. 

I. Interview Summary 

Applicant's attorney thanks the Examiner for the courtesy of a telephone interview 
conducted on August 20, 2009. During the interview, Applicant's attorney and the Examiner 
discussed amendments to Claim 1 and the cited prior art reference Lee. Subsequent to the 
discussion, Examiner indicated that a further search would be performed in an effort to expedite the 
prosecution of this case. 

II. Summary of Rejections 

Prior to the Office Action mailed May 28, 2009, Claims 11,15 and 19 were pending in the 
Application. In the Office Action, Claims 11, 15 and 19 were rejected under 35 U.S.C. 102(a), as 
being anticipated by Lee (U.S. Patent No. 6,480,865). 

III. Summary of Amendments 

The present Response hereby amends Claims 11 and 19, cancels Claim 15 and adds new 
Claims 23-30, leaving for the Examiner's present consideration Claims 11, 19 and 23-30. 
Reconsideration of the Application in light of the above amendments and the following remarks is 
respectfully requested. 

IV. Claim Rejections under 35 U.S.C. § 102(a) 

In the Office Action mailed May 28, 2009, Claims 11, 15 and 19 were rejected under 35 
U.S.C. 102(a), as being anticipated by Lee (U.S. Patent No. 6,480,865). 

Claim 11 

Claim 11 has been amended to more clearly define the embodiment therein. As amended, 
Claim 11 currently defines: 

11. A computer-implemented method comprising: 

generating a transformation file by employing a query language, said transformation 
file containing a set of rules to transform data between two or more formats 
having different shapes; 

attaching the transformation file to a workflow, such that the set of rules are 
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referenced from inside the workflow; 
associating, at compile time, a first shape of a first data structure with an 

intermediate shape representation based on the set of rules of the 

transformation file, wherein the first shape defines a structure and layout of 

data in the first data structure; 
receiving a second data structure during runtime execution of said workflow, said 

second data structure having a second shape that is different from the first 

shape of the first data structure; 
converting the second data structure into the intermediate shape representation; and 
mapping the second data structure from the intermediate shape representation to the 

first shape, wherein the second data structure is converted from the second 

shape into the first shape of the first data structure and using the runtime 

object as input for a component of said workflow. 

As amended, Claim 11 defines that a transformation file is created by using a query 
language (e.g. XQuery). This transformation file is attached to a workflow. During compile time, the 
shape of a first data structure (e.g. a Java data object) is associated with an intermediate shape 
representation. Then, at runtime, when a second data structure (e.g. an XML document) is received 
during the execution of the workflow, the intermediate shape representation is applied to that 
second data structure. At that point, the second data structure can be mapped from the 
intermediate shape representation to the first shape. The engine can then generate a runtime object 
As such, the features of amended Claim 1 enable the use of a query language to transform data 
formats of one shape to a data format of a different shape. 

To illustrate one example of this functionality, a workflow may need to communicate in terms 
of Java objects, where each object has a particular shape (structure, layout) of data. For instance, a 
customer Java class may have a shape that defines an ID, a name and an address. However, the 
workflow may receive an XML document that may have a different shape. In order to translate 
between the two data shapes, XQuery (query language) can used to associate an intermediate 
XML shape representation with each Java object. Thereafter, when the workflow receives an XML 
document of a different shape, it can apply the intermediate XML shape representation to the XML 
document and from there, the data can be easily mapped to the Java object shape by the runtime 
engine. 

Lee teaches a facility for adding dynamism to an extensible markup language. More 
specifically, Lee appears to describe a method for annotating XML documents with invocations to 
Java objects. Once the XML document is annotated, the DXML processor recognizes elements that 
are tagged with prefix tags, processes each of these tags and transforms the XML document 
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accordingly. 

As such, it appears that Lee is concerned with techniques for embedding Java functionality 
into an XML document. However, Applicant respectfully submits that Lee fails to anticipate the 
features of Claim 1 1 , as amended. 

Specifically, Lee fails to disclose generating a transformation file by employing a query 
language, said transformation file containing a set of rules to transform data between two or more 
formats having different shapes, as defined in amended Claim 11. While Lee does mention the use 
of the DXML processor (col. 5-6), there is no mention of any transformation file that is created by 
using a query language. 

Furthermore, Lee fails to disclose attaching the transformation file to a workflow, such that 
the set of rules are referenced from inside the workflow, as defined in amended Claim 11. The 
concept of workflows is not mentioned in Lee. 

Furthermore, Lee fails to disclose associating, at compile time, a first shape of a first data 
structure with an intermediate shape representation based on the set of rules of the transformation 
file, wherein the first shape defines a structure and layout of data in the first data structure, as 
defined in amended Claim 11. Lee is not concerned with associating any intermediate shape 
representations at compile time. This feature of claim 1 can allow the system to associate a default 
XML representation with each Java class, so that this default representation can be later applied to 
the XML data in order to perform shape mapping. None of this functionality is disclosed in Lee. 

In addition, Lee fails to disclose receiving a second data structure during runtime execution 
of said workflow, said second data structure having a second shape that is different from the first 
shape of the first data structure; converting the second data structure into the intermediate shape 
representation; and mapping the second data structure from the intermediate shape representation 
to the first shape, wherein the second data structure is converted from the second shape into the 
first shape of the first data structure, as defined in Claim 1 1 . This feature of Claim 1 1 allows the 
engine to convert between two formats having different shapes by using an intermediate shape 
representation. Lee fails to disclose these features. 

Finally, Lee also fails to disclose using the runtime object which contains data from the 
second data structure as input into the workflow, as defined in amended Claim 11. Since no 
workflows appear to be used in Lee, this feature is also not disclosed. 

In view of the above comments, Applicants respectfully submit that Claim 1 1, as amended, 
is neither anticipated by, nor obvious in view of the cited references, and reconsideration thereof is 
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respectfully requested. 



Claim 19 

Claim 19, while independently patentable, recites limitations that, similarly to those 
described above with respect to Claim 11, are not taught, suggested nor otherwise rendered 
obvious by the cited references. Reconsideration thereof is respectfully requested. 

Claim 15 

The present Response hereby cancels Claim 15, thereby rendering moot any rejection as to 
this claim 

V. Additional Amendments 

The present Response hereby adds new Claims 23-28. Applicant respectfully submits that 
new Claims 23-28 are fully supported by the Specification as originally filed, and consideration 
thereof is respectfully requested. 
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VI. Conclusion 

In view of the above amendments and remarks set forth above, it is respectfully submitted 
that all of the claims now pending in the subject patent application should be allowable, and 
reconsideration thereof is respectfully requested. The Examiner is respectfully requested to 
telephone the undersigned if he can assist in any way in expediting issuance of a patent. 

The Commissioner is authorized to charge any underpayment or credit any overpayment to 
Deposit Account No. 06-1325 for any matter in connection with this response, including any fee for 
extension of time, which may be required. 



Respectfully submitted, 



Date: August 20. 2009 By: /Justas Geringson/ 

Justas Geringson 
Reg. No. 57,033 



Customer No. 80548 
FLIESLER MEYER LLP 
650 California Street, 14 th Floor 
San Francisco, California 94108 
Telephone: (415)362-3800 
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